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ABSTRACT 

HyTime defines an extensive meta-language for 
hypennedia documents, including general representatians 
for links and anchors, a finamework for positioning and 
projecting arbitrary objects in time and space, and a 
structured document query language. Wc pruposc a set of 
criteria for evaluating the HyTime model. We then review 
the model with respect to these criteria and describe our 
implementation experience. Our review indicates both the 
benefits and limitations of HyTime. These results are 
relevant to systems and applications designers who are 
considering HyTime, and also to possible future revisions 
of the standard. 
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INTRODUCTION 

Since 1991 we have developed various hypennedia systems 
and applications which arc based on the HyTune ISO 
standard [17]. This work includes: 



1. 
2. 

3. 



5. 

6. 
7. 



A HyTime engine based on an OODBMS [1] 

Examination of automatic HyTime application 
generation[5] 

Examination of different approaches for integrating 
multimedia scripting languages with Hyllme[3] 

Potential relationships between H/Time and 
HTML[25][27] 

An implementation and evaluation of the HyQ query 
language[6j 

An archiiecnire for a distributed delivery model t7][8] 
A graphical representation for HyTune document 
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8. A proposal for an open hyperdocimieni architecture 
based on HyTmie [7] 

In this paper we present an evaluation of HyTime based on 
this research experience and with some consideration for 
the requirements for hypeimedia document architecture as 
developed by various hypermedia researchers. 

The HyTime specification was developed in the context of 
hypertext practice in the late 1980s. Additionally, musical 
dme models, originally developed for the SMDL (Standard 
Musical Description Language) standard, were generalized 
in HyTime's scheduling and projection modulcs[24]. 
Further, some facilities in HyTime arc improvements to 
SGML (Standard Generalized Markup Language). Since 
this time, significant developments have occurred in the 
design of distributed hypermedia systems, multimedia 
media formats, multimedia scripting languages and 
authoring paradigms. Also, new distributed object 
ftameworks are providing an environment for creating 
hyperapplications. These developments provide a new 
context in which to consider the design and use of 
HyTime. 

Prior to its standardization. litUe of HyTime was validated 
by implementation. Subsequent to its standardization, only 
a few inq)lementations of subsets of HyTime exist, in part 
because of the complexity of the specification. Complete 
validation would require significant experience with: 

Interchange between different hypeimedia systems 

Multimedia DTD (document type definition) design 

Creation of large heterogeneous hypermedia document 
collections 

Nevertheless a useful assessment can be made based on the 
criteria that we present in a later section. This assessment 
is valuable for designers of hypennedia systems, 
hypermedia documents, and other hypeimedia standards, 
as well as for those interested in HyTime. 
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In ihis paper we present an analysis of HyTime as a meta- 
language for hypennedia documents. We define our 
evaluation criteria, and then examine Hylime according to 
each of these criteria, noting both positive and negative 
aspects. Since HyTime has been described in several places 
[9][24), we omit a HyTime tutorial. Thert is an ongoing 
activity to develop conventions for the use of HyTune by 
the user group known as CaPH. We do not address this 
work in this paper. A number of HyTime facilities are 
extensions or improvements of SGML features. Since our 
interest is in hypennedia semantics, we do not address diis 
particular area in this papei. The next section provides an 
overview evaluation, drawing upon the context and basic 
philosophy of HyTime's development Section three 
present a set of criteria for evaluating HyUme. Subsequent 
sections discuss HyUme with respect to these criteria. The 
last section summarizes the paper. 

SOME GENERAL OBSERVATIONS 

When HyTime was developed, the praaice of hypertext 
could be characterized as stand-^one systems which used 
different models for document structure, anchors, links, 
navigation, and other key features. A basic problem was 
the ability to interchange hypertext documents between 
systems with different models of hypertext HyTime was in 
part conceived as a solution to the problem of interchange 
of content between different hypertext systems. For 
interchange purposes, a given hypertext system could 
define a RyTmt DTD and then export content as a 
document instance for this DTD, A system receiving this 
document instance, which in this example would have 
defined its own HyTime DTD, would attempt to translate 
the elements and attributes of the imported document to 
corresponding dements and attributes of the native system. 
In so far as each DTD is able to use HyTime facilities for 
representing these elements and attributes, the translation 
would be simplified and the amount of custom software 
and manual intervention would be minimized. 

HyTime was developed by the same committee that created 
„,.tlie SGML standard, and tJiC primary target of HyTime is 
the SGML tx)mmunity. Li particular, HyTime itself is 
defined as an SGML meta-DTD, and use of HyTime 
requires use of SGML. Now with the rapid evolution of the 
worid-wide web (WWW), there is also the prospect that 
portions of the much larger HTML community will 
migrate to SGML. HyUme is a natural evolutionary 
direction for an SGML web. We discuss this scenario in 
previous work [6] and briefly evaluate the relationship 
between HyTime and WWW later in this paper. 

HyTime is a mcta-language for creating new hypennedia 
document types. An application designer identifies the 
structural elements that are suitable for the target 
document type. When constructing the application DTD, 



the designer uses the corresponding HyTime architectural 
forms which fit the semantics of the corresponding 
elements and attributes. Application structure which is not 
representable with HyTime faciUties can be represented by 
defining application specific elements and attributes. 

The meta definition is a syntactic mechanism and does not 
increase the semantic capability of HyTime, The meta- 
DTD definition of HyTime has some benefits when 
compared to the alternative of defining a single standard 
hypwmedia DTD: 

L Backward compatibility with existing SGML 
applications 

The meta definition makes it easitt to incoiporaie facilities 
of HyTune into existing SGML DTDs without modifying 
the names of existing elements and attributes 

2. Multiple HyTune-based DTDs 

Many different application DTDs can be defined as 
appUcaUons of HyTime, Similarly, the instances of many 
different DTDs can be included in the same HyTune 
hypermedia document set 

3. The name space for element generic identifiers (GI) is 

more flexible 

The HyTime meta-DTD doesn't define any GIs, and more 
than one application GI can use a HyTime ETF (Element 
Type Form). Additionally, an application can define its 
own non.HyTime GIs. and has complete control over 
attribute names. 

The meta definition, however, complicates the use of 
HyTime since it leads to an additional level of indirection. 
That is. the designer of a tag set must conceptuaUy work at 
one additional level, the meta-DTD level, when defining 
elements and attributes for the application DTD,. 

Previously [7] we have argued that HyTime. as a standard 
for hypermedia document models, offers the possibility of 
increa.sed generality in the design of hypermedia delivery 
systems. TTiis is shown in Figure I . 

Since many hypermedia applications share structural and 
composition requirements-in particular time, space, and 
hyperlirUcs-a standard description of these components of 
applications means that less custom code is needed to 
deliver the application. At the same time, HyTune is 
almost entirely silent about presentation and interaction, 
and so is an incomplete way of describing most existing 
hypermedia and multimedia documents, Consequendy it is 
impossible lo deliver any hypermedia application by 
providing only a HyTime document instance and DTD lo a 
HyTime engine. Unlike SGML applications which operate 
with a document instance, DTD, and style sheet, typical 
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impossible to deliver any hypermedia application by 
providing only a HyTime document instance and DTD to a 
HyTime engine. Unlike SGML applications which operate 
with a document instance, DTD, and style sheet, typical 
HyTime applications appear to require custom software 
beyond the HyTime engine (7J. This custom software is not 
just for the media specific presentation. Custom software is 
required for all time, space, and interaction semantics for 
presentation. This means that each time a new HyTime 
DTD is created for a new application, some custom 
presentation software must also be developed. We discuss a 
way to mitigate this later in the implementation section. In 
previous work [7] we have investigated the feasibility of 
automatically generating some or all of the application 
presentation software from the application DTD. By 
adopting certain conventions, a significant portion of the 
presentation software could be automatically generated, but 
it is not a complete solurioit 
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Figure 1. Progression of generality In hypertext engine 
design: 1) completely custom architecture, 2) storage 
of hypermedia Information In a backend database (first 
done In mid-1980s), 3) exporting a link database on top 
of the database, 4) supporting generic muftlmedia and 
temporal modeling constructs. Most systems today are 
at stage three. A HyTime engine Is a stage four system 

CRITERIA 
Standardization 
Functionality 

Any attempt to standardize a hypermedia document 
architecture must please a diverse set of applications. 
Additionally, international standards have a projected 
lifetime of five to ten years, and it is a challenging task for 
the designers of a standard to specify a framework which 
will remain adequate in the face of an evolving field. 
Further, standards frequently define many options or 
profiles which permit a flexible range of uses but at the 
same time may appear as unnecessary minutia to the 
observer. Finally, compatibility with other standards is also 
an important consideration. 



The question of what should be standardized and what 
should be left for applications to decide is a crucial one. 
Figure 2 shows a high level view comparing HyTime 
facilities with the space of hypermedia functionality. In 
this space HyTmie focuses on representing structure of 
both the hypergraph and the nodes of the hypeigraph. 
Delivery issues including interaction and presentation 
facilities, integration with computation engines and other 
^plications, and autfioring paradigms are outside the 
scope of Hynme. 




Figure 2. HyTime facilities as a subset of hypermedia 
systems functionality 

Criteria 

Each of the following sections examines HyTune 
according to one of the following perspectives: 

1. Representational completeness 

The most basic question is whetiier HyTime is 
representationally complete for the functionality it 
standardizes. This question can be addressed by developing 
a statement of requirements and comparing HyTime with 
this statement, and by comparing HyTime with otfier 
formal models of hypcnncdia Uiat have been developed. In 
this paper we take this latter approach. A related question 
is whether a HyTime system is operationally open and 
extensible. 

2. Technical correctness and completeness 

Given the scope of representation, tiie next question is 
whether HyTime modules and architectural fornis (AFs) 
correctly and completely provide the intended scope. This 
question can be partially addressed by interpreting the 
specification, and by using HyTime to encode specific 
hypermedia document structures. 

3. Relationship to the WWW and other more recent 
developments in the practice of hypertext 

Another measure of HyTime is its flexibility for use in 
contexts which have emerged subsequent to the 
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specification of the standard. These contexts might 
include: 

Virtual reality, e.g., ihe use of HyTime to represent 
hypcrlinking in/between virtual worids 
Integration with content-based retrieval methods, e.g., 
to create anchors to non-text media 
HyperapplicatiDns, e.g., the relevance of HyTime to 
representing hyperlinks betweai applications 
4. Implementation experience 

Implementation experience with HyTime can be used for 
determining the efficiency of systems which process 
HyTime for delivery and interchange, and for evaluating 
the complexity of the HyTime processing architecture 
versus the resulting functionality. 

REPRESENTATIONAL COMPLETENESS 
Compariso n to the Dexter Hypertext Model _ 

TTie Dexter hypertext model is a formal model developed 
in the late 1980s as a generalization of the leading 
contemporary hypertext systems [13]. The model divides 
hypertext delivery systems into three laycn, with most of 
the emphasis on the storage layer. A key insight of Dexter 
is the identification of anchors and links as distinct entities 
in the hypergraph. In Dexter the anchor encapsulates the 
content-specific address of the link endpoint, isolating the 
link from the details of how the content is organized. 
Subsequent work has extended the Dexter model to permit 
dangling links and the ability to define anchors for 
composite nodes. 
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Figure 3. Overlap between the six HyTime modules and 
the three layers of the Dexter model 

Figure 3 shows the overlap between the six HyTime 
modules and the three layers of Dexter. The within- 
component layo^ corresponds to the HyTime location 
address module, and the storage layer corresponds to the 
hyperlinks module. like Dexter anchors, HyTime location 



address forms isolate links from the details of content- 
specific addressing. HyTime, however, provides many 
different addressing techniques that can be used to form an 
anchor (Table 1). These forms can be directly applied to 
any text content An application can also define its own 
content spedfic notations and create Hyilme anchors 
which use these notations. A set of different addresses can 
be aggregated (aggloc) in various ways, and a set of 
addresses can define the span of an anchor (spanloc). 

HyTime introduces the notion of a location ladder which 
generalizes the concept of an anchor. Any location 
reference can refer to an already existing location, and an 
arbitrary series of location references can be chained 
together. This allows a newer anchor, perhaps created in a 
different document owned by another user, to build upon 
existing anchors. HyUmc also permits anchors to be 
formed dynamically using the HyQ query language 
described in the nex t section. - — ^ 



Table 1. Summary of HyTime addressing forms 



Address 
Attribute 


Brief DescriptioQ 


Name space 


Position based on unique name 
associated with document node 


Data 


Position based on treating content as 
ordered units of quanta 


Node 


Position in docimient structure, 
including locating by position in: 1) 
documem tree, 2) one or more paths in 
a tree; 3) position in a list of nodes of a 
document; 4) relative position with 
respect to some other node 


Property 


Position based on prcvperty attributes 
associated with nodes 


Bibliographic 


A bibliographic reference to off-line 
material 



HyTime generalizes Dexter's link and anchor model, 
adding many mechanisms for addressing content as well as 
permitting application define their own content-addressing 
notations. HyTimc permits dangling links, and allows 
anchors to refer to composite nodes. HyTime anchors can 
also reference objects that are positioned in time or space. 
HyTime links and anchors can be placed in separate 
documents from which the addressed content is stored. 

HyTune doesnt provide a starulard mechanism for 
applications to associate presentation attributes or 
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Time Modal 

Time is a fundamental compositional notion in multimedia 
and hypermedia documents. Although HyTime has a 
scheduling module, there is no explicit time or space axes, 
but simply arbitrary dimensions which the application is 
free to interpret as it wishes. For example, one might place 
a series of images in a HyTime axis named *'t" and 
associate units of seconds with this axis, but HyTinie 
doesn't prescribe whether these images should be ^wn in 
time order to the user, or whether they jusl happen to have 
an intrinsic chronological relation, such as the order in 
which they were painted by an artist The interpretation of 
the axis in time or space is left to the explication. 

Erfle [10] has evaluated HyTime's coordinate axes and 
position mechanisms with respect to the requirements of 
temporal compositioiu and concludes that for fifteen issues 
of interest, HyTune is compositionally sufficient. Recent 
work [15] in translating the Amsterdam Hypermedia 
Model to HyTime shows that HyTime is adequate for 
representing the paraUel time channels and 
synchronization edges used in AHM. 

One important area is the ability to represent 
synchronization relationships. In multimedia documents, 
the specification of a synchronization relationship between 
two or more media allows the presentation system to 
properly coordinate synchronization recovery in the event 
of unexpeaed delay in one or more of the media channels. 
The HyTime standard states (clause 7.4): 

"It can be useful to specify all or part of a dimension in 
terms of components of another dimension. For some 
applications, this technique could be used to represent 
alignment and synchronization relationships." 

The dimension of one event in a HyTime schedule can be 
defined relative to another event. If, during presentation 
delivery, a presentation delay occurred for the referenced 
event, then a delivery system might infer that the relative 
event should also be delayed or resynchronized. However, 
there is no way within HyTime for an application to 
specify that such alignment relationships should be 
interpreted as synchronization points. 

In the case of temporal structure, HyTmie provides 
facilities which can be used to represent both temporal 
composition and temporal synchronization, but the 
temporal semantics are left to the application to determine. 

Comparison to Halasz* Third Gonoratlon Systiem 
Halasz [14] described seven areas wiiich third generation 
hypermedia systems must address. These issues, and the 
relationship of HyTime to them, are shown in Table 2. 



HyTime appears to be suitable for interchange between 
second-generation hypermedia systems. 



Issue 


Description 


HyTime Support 


Integration of 
Search and 
Query 

Functionality 


Integration of 
information 
retrieval and 
DBMS facilities; 
pattern matching 
languages for 
hypergraph 
manipulation 


Partial, through 
the availability of 
HyQ, the match 
function, and 
application-defined 
queo^ notations 


Composite 
Node Types 


In addition to 
content nodes, 
need container or 
collection nodes 


Yes; each non-leaf 
node can be a 
composite (also in 
SGML) 


Virtual 

Structures over 
Node 

Collections 

t. 

c 


Computationally- - 
defined 
hypergraphs. 
analogous to 
database views 


Partial, through 
use of the HyQ 
query language 
combined with 
linking and 
location addressing 


Computation 
over 

Hypermedia 
Networks 


Integrated 
computational 
engines available 
to the application 


No; must be an 
external process; 
no specific features 
for integrating 
with external 
processes 


Versioning of 
Nodes and 
Subgraphs 


Maintaining 
change history at 
botii node and 
graph level; 
version 

identification as an 
attribute in search 
and query 


No; not considered 
to be within the 
scope of the 
standard 


Support for 

Collahonuive 

Work 


Support for shared 
access to 
hypertext, and 
group protocols 


No; not considered 
to be within the 
scope of the 
standard 


Extensibility 
and 

Tailorability 


Easier 

customization of 
hypermedia system 
by end user 


Partial, through 
the definition of 
new DTDs 



Table 2. Halasz'fi [14] seven Issues for third-generation 
hypermedia eyeteme 
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Hypermedia Structure, Semantics, 
and Presentation and Interaction 
A fundamental tenet of SGML and HyTime is that logical 
structure of documents which have archival value should 
be separated from presentation specific attributes. SGML 
applications use a style sheet to defme layout and format, 
and many different style sheets could be used with the 
same document instance. 

Multimedia and hypermedia implications are only partially 
about logical content organi7^on. Hiey are also about 
creating an interactive audio-visual experience, and the 
artist who develops a multimedia presentation might 
consider the stylistic aspects intrinsic to the composition. 
As observed earlier, HyTime defmes no mechanisms for 
integrating application scripts or for defining interaction or 
presentation attributes. It has limited support for 
associating browsing semantics with the hypergraph 
structure. 

HyTime lakes .a conservative' position as to the need to 
represent presentation and interaction semantics, and 
provides structuring mechanisms with litde semantics. 
Consequently, HyUme is not a self-contained vehicle for 
interchanging hypermedia and multimedia infomation. 
While it provides a declarative notation which is desirable 
for archival and processing purposes, its limited semantics 
lead to increased q)plication-specific processing, whether 
for presentation or for retrieval. 

SELECTED DESIGN FEATURES AND TECHNICAL 
CORRECTNESS 

Modularity and Incremental Use 
The HyTime structuring language includes sixty-nine 
element type fom\s (ETP) and twenty-four attribute list 
forms (ALF)- Many applications of HyTime need only a 
subset of these facilities. Through the use of HyTime 
support declarations, an application DTD can identify 
which modules and options are required for the application 
to be properly interpreted. 

It is also possible for an SGML application lo use 
individual HyTime architectural forms, but such an 
application won't be a conforming application. 

A stated objective of HyTime's support declaration is to 
permit an application to require only the relevant subsets 
of HyTime. For example, the standard defines a continuum 
of five docuincrii dcclamdons which range from minimum 
to fairly full use of the facilities of the six modules. We 
have developed a simple HyTime application called HMP 
[1] (Hypermedia Presentation) which uses only ten ETFs 
but has a support declaration which inq>lies twenty-seven 
ETFs. Any interesting multimedia application will 
probably have a sup];>ort declaration comparable to that of 



the Basic Schedule declaration-forty-eigjii AFs 
(architectural forms)— but might need significantly fewer. 

Analysis of the dependencies between modules and 
architectuml forms shows that many AFs can be used 
independently. The support declaration specification in 
HyTime is not sufficiently fine-grained to take advantage 
of the relative bidependence of AFs. A fine-grained 
approach, for example, would allow an application to list 
only the AFs that it needed. The advantage of a fine- 
grained approach would be that an engine implementing a 
small but useful subset of HyTime, such as the HMP DTD, 
could still be HyTune confoiming. 

HyQ 

HyQ is a query language whose domain is one or more 
HyTune documents. A HyQ query returns node lists, where 
nodes are element structure within an SGML/HyTime 
document. HyQ can be used to form dynamic anchors, or 
could be used by an.extemsd application. HyQ is defined in 
an appendix of IS 10744. In previous work [6] we analyze 
HyQ through a series of twenty-five examples. We have 
also implemented a HyQ processing system and tested a 
number of these queries. 

HyQ is a restricted functional language. It is a side-cffea 
finee language (except for the fairly restricted Assign 
operator). It has limited conditional execution constructs. 
It focuses mostly on manipulation by querying zs opposed 
to manipulation by dynamic creation. It appears to permit 
recursive functions to be written, but because of the lack of 
conditional flow of control constructs, writing a 
termination condition for a recursive HyQ function appears 
tricky. It is clumsy at best to write HyQ queries which 
ideiuily nodes which minimize or maximize some 
attribute. We note also that the inability to re-order node 
lists, for example by sorting them, seems to be a linutation. 
There are no arithmetic operators. 

In p^c^'ious work (61 wc have analyzed the computational 
facilities of HyQ, in particular the. ability to. query the 
hypCTgraph network. We have developed HyQ exan^les 
for the following types of queries: 

Obtaining the anchors of a link 

Obtaining the links attached to a given anchor 

Fmding the anchors for a givai andior role for the 
hyperlink 

Hnding die d^th one web from current document 
Halasz' issue-position query [14] 

Guided lotir via keyword attribute or keyword in content of 
node 

These queries use one or more of the node properties 
defined by HyTime as shown in Table 3. The interpretation 
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of these hyperlink properties in a multiple document 
context is not clearly defined by the standard. For example, 
it is not specified whether the linkcdby property would 
identify all hyperlinks in all documents that use this 
anchor, or whether only a subset would be identified. 



Name 


Description in ISO 10744 


hylink 


ilink or clink element 


anchon 


objects linked by hylink 


ANCHROLE 


anchor roles of anchors of 
hylink 


linkedby 


hylinks that link an anchor 


linked to 


other anchors of linkedby 


LINKEDAS 


rol&of anchors in hylink ' 



Table 3. Link properties (uppercase/lowercase symbols 
as given in the standard) 

It is possible to use HyQ to do sophisticated structure 
querying against the hyperlink web. Much of HyQ's power 
comes from its tight integration with HyTime's location 
addressing facilities sununarized earlier. The content 
matching capability, based on the HyLex regular 
expression language, is weak compared to common 
information retrieval techniques. There is no specific 
support for integrating HyQ with retrieval functions that 
return ranked results. 

There are ways to extend HyQ, as well as define an 
application-specific query language as an alternative to 
HyQ. This would limit the portability of the document 

A soon to be completed corrigendum of HyTime is 
expected to replace HyQ with the more powerful SPQL 
query language defined in the DSSSL standard. 

Addressing Media Objects 

The nature of multimedia documents is that much of the 
content of the document will be in binary files external to 
the HyTune document HyTime's role in a multimedia 
document is to connect all the pieces of the presentation 
and represent tiie strucniral relationships between them. 
Important relationships may include spatial, temporal, 
composition, transformation, and hyperlinking. All media 
and non-Hylime files will be interpreted and presented by 
processes separate from the HyTune processing system. 
HyTune is neutral with respect to the formats used by non- 
HyTune files. It does provide architectural forms for 
supporting location addrossing of objects in non-Hylune 
formats* and for representing hierarchical external entity 



structure when the media entity of interest is embedded in 
a container entity. 

HyTime extends the SGML facilities for dealing with 
binary entities, HyTune defines two data content notation 
ALFs in the base module, sbento and any-dcn, which are 
data attributes for entities. Together they can be used to 
fomially describe an external entity which contairu nested 
entities. Common examples of this in multimedia data are 
frames in a video sequence, audio tracks in a movie file, 
and color tables in graphics files. We have created an 
example that uses sbento and some of the attributes of any- 
dcn to create an entity reference to a frame in an MPEG 
video sequence. MPEG, a recent ISO standard for 
compressed digital video and audio, composes its bitstzeam 
in a hierarchy, defmed as follows: 

A video sequence consists of one or more groups of 

picttires _ , . . _ „ , . 

A group of pictures consists of a set of pictures 
A picture consists of a set of slices 
A slice consists of a set of maooblocks 
A macroblock consists of a set of blocks 
A block is an 8x8 pixel array 

The top two levels of the hierarchy petmit random access 
to the video frame level. The lower levels are fundamental 
part of the encoding and decoding algorithm, but could 
also be used by the s^plicadon to address sub-elements in a 
frame. 

The sbento content addressing mechanism requires 
complete enumeration of the extents of all containers in 
the hierarchy. This may be impractical for lengthy 
continuous media sequences, or for encodings which are 
generated dynamically. 

Rendition Module 

In the rendition module, HyTime provides a framework for 
representing object modification and transformation. These 
facilities might be used to specify how media objects: are to 
he rendered to the presentation space or the type of 
transition effect to use for displaying a media object 
However, the rendition facilities are defined at an abstract 
level, and presentation semantics are left to the application 
to interpret Similarly, location addressing of external 
media formats depends on formal notatioas being specified 
for those fonnats. These would be integrated with a 
HyTune document by adding an SGML notation 
declaration. 

Activity Tracking 

Selected portions of document structure can be moiutoied 
by the HyTime engine for specific types of user access, 
including the operations of creation, deletion. 
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modification, access, link, and unlink. The engine will 
report each type of access to the application. This 
innovative facility has many potential applications. 

RELATIONSHIP TO OTHER RECENT DEVELOPMENTS 
HTML and WWW 

The ultimate validation of a standard is when a significant 
community of users adopts the standard. HyTime is a 
recent standard, and has had virtually no commercia] 
impact as yet Yet during the same period a much more 
limited hypertext modeL the HypetText Markup Language, 
has grown explosively in use. HTML 2.0 is now defined as 
an SGML DTD. 

HTML linking is a semantic subset of HyTmie's location 
addressing and hyperlink modules. There is no comparable 
facility in HyTune for HTML forms. HyUme facilities for 
time-space positioning, projection, rendition, location 
addressing, etc., have no counierpan in HTML. Rutledge 
ct al. [25] have shown ihat^HTML can be defined as a 
HyTune DID [27]. 

The need for archival content delivered via WWW may 
lead to web viewers providing general SGML support 
Activities such ACMs electronic publishing proposal and 
the Text Encoding Initiative (TEI) are examples of 
electronic publishing applications for which HTML is 
insufficient. The W30 developer libraries are being 
arcliitected to support client-side SGML parsing. We have 
previously argued [7] that opening the web to provide an 
open DTD aq)ability at the browser would fiee 
applications from the limitations of HTML. In this 
approach, any legal SGML DTD and document instance 
could be uploaded and delivered. 

Once SGML is supported at the client, support for HyTmie 
is technically feasible and would provide a much richer 
hypcnnedia framework, 

"What we really need (to repeat), is a general 
addressing mechanism similar to that offered by 
HyTime. If we continually reinvent addressing 
schemes with different syntaxes, it makes supporting 
all the various syntaxes a real headache. One general 
(and extensible) syntax is far more preferable," — 
posted to the http-wg list during discussion of htqj 1.1 
features to support addressing of media. 
Video Dlattone and Video on Demand 
Video Dialtone [23](11] is a framework for multimedia 
content and on-line consumer information services 
delivery via an interactive television interface. The content 
architecture being proposed for video dialtone netwoits by 
the DAVIC consortium is a combination of MPEG-2 
(video, audio, systems, and DSM-CQ and MHEG-S [20]. 
MHEG-5 is a subset of MHEG-1 [18] which, as discussed 



in previous work [2], has been designed for incremental 
delivery of interactive script-based multimedia content in a 
distributed environment. MHEG, unlike HyTune, is a 
final-fomi encoding and was designed specifically for real- 
lime delivery over networks. 

In con^)arison to MHEG, HyTune does not repieseni 
interaction and presentation aspects of multimedia content 
It is not well suited for an incremental delivwy model, 
since SGML must be parsed sequentially. Additionally, our 
implementation experience with both MHEG [4] and 
HyTime [1] indicates that an MHEG engine is 
significantly simpler and requires less memory, an 
important consideration for consumer devices. 

Virtual Reality 

Another WWW developmaii, VRML (virtual reality 
markup language), demonstrates that it is possible to 
combine hyperlinking with three-dimensional scene 
navigation in a useful manner. Assuming' that the 
encoding of the cyber world were done in a specially 
designed format such as VRML or MPEG-4. HyTune 
notation location addressing combined with an appropriate 
notation definition could be used to create a HyTune 
hyperlink structure over a set of virtual reality scenes or 
worlds. 

Content-Based Retrieval 

Recently there has been progress in image and video 
retrieval techniques suitable for multimedia databases and 
authoring [12]. Such algorithms are the basis for defining 
notations for representing anchors in visual media. As is 
the case for VR, HyTune notation location addressing 
could be used with such a notation to permit HyTime 
documents to link to addressed portions of visual content 

Hyperappllcatlons 

Several object-oriented application frameworks have 
appeared recently, and some of these support the ability to 
embed one application in another application's display 
area. These frameworks do not currently define an explicit 
declarative hypcrgraph representation that can be accessed 
by an arbitrary application. Rather, the linking and 
embedding mechanisms are accomplidied 
progranunatically. Making the hypergraph structure 
explicit would make it possible to support link browsers 
and searching and filtering facilities for links. 

Persistent storage of hypcrgraph and the explication 
anchors and navigation methods is needed to preserve the 
associative iitformation between user sessions. HyTime 
provides a generic model for links and location addressing. 
The HyTime location addressing fornis might be usefiil for 
applications which manage documents. The ultimate goal 
would be a hyperbase which could support both the 
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document architecture and the hypcrapplication 
framework. HyTune link and location address could be a 
useful part of the design of such a hyperbase. 

IMPLEMENTATION EXPERIENCE 

A HyTime engine takes as input the parse tree produced by 
the SGML parser. It perfonns HyUme-spccific validation 
of the parse tree, and may create special index structures to 
make navigation of the HyTime constnicts in the document 
more efficient It provides a HyTime-specific application 
programmer interface so that an application can transverse 
the document tree and locate the HyTime structures of 
inieresL The HyTune standard does not specify the design 
of HyTune engines, nor does it define an API. A natural 
way to organize this API. as we describe in the 
development of die HyOctane'" HyTime aiginc [1], is to 
provide classes which are associated with each functional 
area such as linking, locating, scheduling, etc. 

A- HyTune application -accesses the HyTime document - 
structure stored in the uigine and presents this to the user. 
User interaction may lead to presentation state change, and 
ultimately to navigation within the document. All 
presentation and interaction decisions are handled by the 
application. Any non-trivial HyTime application will 
require specific software or scriptware in order to 
implement the presentation and interaction semantics. 
This is an impediment to the development of HyTime 
application development and delivery. On the development 
side it means that an application developer faces both a 
DTD design task and a programming task. On the delivery 
side, while the HyTime document instance is portable, the 
application software or scriptware that interfaces with the 
engine is generally not Our solution to this problem [7] is 
to integrate the HyTime engine with a standard script 
player, such as the virtual machine player specified in 
MHEG-3 [19]. This addresses the portability issue of the 
preseniation^teraction software and also makes the 
delivery model open to arbitrary scripting languages. In 
this model, an application designer creates a HyTime DTO 
and writes a presentation script for this DTD, The" 
presentation script is interchanged with the DTD and 
document instance whenever the document is to be 
delivered to the end user. We refer to the resulting delivery 
architecture as an open hyperdocument model. 

The initial client-server model of our engine used a server- 
side OODBMS to store the parse tree directly as a tree of 
objects. This mapping turned out to be inefficient for 
storage of large numbers of documents. Subsequently we 
have revised the internal organization to create a compact 
representation of the document which is still convenient 
for indexing sub-stnacture within the document Our 
measurements to date indicate that the compact OODBMS 
storage format that we have designed is compressed fiom 



the native text files by a ratio of 3.5:1, These 
measurements on based on a Hyllmc application wc have 
designed called HMP (Hypermedia Presentation DTD). We 
have done similar measurements on storing parsed HTML 
2.0 documents in the database. For snmll documwus (IK to 
3K bytes) we obtained compression ratios in the range of 
1.5: I to 2,0:1. For a large document (about 300K bytes) 
we obtain a compression ratio of 3; 1. 

We obtain more cojnpression for HyTime documents than 
HTML documents due to two factors. First, a HyTime 
DTD like HMP has many levels of nesting due to the 
structural requirements in the HyTime meta-DTD. For 
example, to associate a location with an image in a HMP 
document the HyTime meta-DTT) requires it to be three 
levels down from the root clement of the document This 
high degree of nesting results in many repetitions of an 
element's begin and end tags. Second, HMP documents 
also use a large number, of attributes. Most elements in a 
HMP document have no data, but contain several 
attributes. This is due to HyTune element type forms 
which make extensive use of attributes. HMP is a 
representative HyTime DTD. Its extensive used of 
attributes and the high degree of element nesting arc a 
direa result of the requirements placed on it by the 
HyTime meta-DTD. Our server-side preprocessing and 
storage technique takes advantage of these two features, 
leading to more efficient storage and delivery of HyTime 
(as well as HTML and SGML) documents compared to 
existing systems. 

In summary, the Distributed HyOctane™ engine has three 
fundamental feanires: 1) the document model is open to 
any HyTime or SGML DTD, including HTML, 2) the 
hypermedia semantics of HyTime related to links, 
time/space, and anchoring arc available, 3) the server 
stores a preparsed compact version of the document, 
simplifying the design of the client and leading to reduced 
networic overhead. We have developed a HyTime 
application called HMP (HyperMedia Presentation). The 
HyOctane engine uses a OODBMS to store parsed 
documents as objects. It ako implements the HyQ 
document query language. The HyOctane engine is 
interfaced to an http server which passes the preparsed, 
compact HTML and HyTune documents to the client for 
direct presentation, (Compared to the currwit httpd server 
design, the HyOctane approach: 1) saves significant 
storage space at the server: 2) eliminates the need for client 
side parsing; 3) reduces the amount of information being 
transmitted over the network; 4) is the basis for 
inaemtaital delivery of SGML-encoded documents; 5) 
facilitates server-side document structure queries. 
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SUMMARY 

HyTimc is concerned with addrtxfsing, associating, and 
structuring of hypenncdia information. In these areas it 
provides a general and extensive set of architectural forms. 

HyTime has attracted some interest bodi because of its 
position as an international standard and due to the 
elegance and innovation of its general design. On the other 
hand it remains enigmatic to many us^ due to its 
complexity and meta-SGML relationship. Translating 
multimedia documents authored in today's commercial 
tools to HyTime remains a complex task. 

During the period of HyTime's development, relatively 
little had been done to deliver interactive composite 
multimedia content in hypermedia systems. Similarly, 
hypemiedia query languages were also relatively novel 
Consequently in these areas HyTmie had a smaller 
reser\'oir of experience to draw upon. 

For multimedia applications? there" are significant 
representational limitations with regard to interactive 
behavior, support for scripting language integration, and 
presentation aspects. In these and other areas noted in the 
paper, the designers chose for the most part to avoid 
defming a semantics while at the same time defining 
extensive structural facilities. This strategy is in keeping 
with the logic markup tenet of SGML. However, for 
multimedia applications these omitted areas are tjpically 
an intrinsic part of an overall composition created by a 
designer, and must currently be expressed in an 
application-specific way. 
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